Modernly, usage of PCs (personal computers) is quite commonplace, yet still growing. Affordable hardware becomes faster and has more capabilities and capacities with each passing year. Application software to handle new tasks and system software to handle new devices continues to emerge.
For various reasons, many emerging personal computer designs will incorporate Hypervisor programs or VMM (Virtual Machine Monitor) programs which are at least closely related. Moreover the Hypervisor is expected to be located deep in the computer architecture having a crucial supervisory role over at least some of the computer hardware; most notably the CPU (Central Processor Unit) time resource, which is closely tied to circuitry clock cycles.
As such, Hypervisors make a particularly attractive target for malware which is growing problem. Various improvements that target malware have been proposed but one of the more promising approaches is to run a computer's general purpose software under the control of a hypervisor and to harden the hypervisor against attack. Part of the reasoning behind this approach is that malware attacks on software are modernly through design or implementation flaws in the software itself.
Moreover, the most highly valued (by both users and attackers) applications can be relatively simple and contrasted with lower value applications which must often be complex. A good illustration might be online banking (capable of being kept simple and great wealth may be at stake) as contrasted with online game playing (might involve complex imaging and animation but often with little or no money being at stake).
One approach, taken by Phoenix Technologies® Ltd., assignee of the present invention, is to provide a small hypervisor (for example the HyperCore™ product) which is tightly integrated to a very few small hardened application programs. HyperCore™ also hosts, but is only loosely connected to, a general purpose (complex) computer environment or operating system such as Microsoft® Windows® or Linux®.
In order to achieve its aims of being small and hardened against attacks, HyperCore™ is necessarily limited in features to the minimal subset required in the circumstances. In particular, HyperCore™ supports only one complex O/S (Operating System) per session and does not virtualize most resources. In this context, session may be defined as a temporal interval extending from a power-on bootload to a reboot or power-off condition. In a HyperCore™ environment, most resources are not virtualized but are made available on a simple pass-through basis to the one and only complex O/S that is present. The small hardened applications have only a minimal subset of virtualized resources (such as the mouse keyboard and screen whenever the hardened application has the execution focus and a share of CPU cycles and of virtual memory). In summary then, at any one time HyperCore™ hosts one complex O/S with applications running under that O/S and in addition, HyperCore™ simultaneously hosts a number of small and trusted applications which are hardened against malware attack.
Various security measures, notably incorporating TPM (Trusted Platform Module) exist to establish a chain of trust that enables a hypervisor to be assuredly clean (i.e. not compromised by malware) at the time it is loaded. This is based on making the very reasonable assumption that the computer can be manufactured and initially loaded with firmware and software in a secure environment where it is not at risk from malicious attack. Indeed it is probably fair to say that almost all malware attacks come through data communication (mostly Internet) or removable media (e.g. Unified Serial Bus (USB) “Flash Drives”) after the computer leaves the controlled manufacturing and distribution environment.
It is important that protection of hypervisor and hardened applications includes but is not limited to ensuring they are not tampered with as of when they are loaded and that the code is itself thoroughly debugged. In order to be thoroughly debugged code (parts of the hypervisor and the hardened applications) must be kept relatively simple and therefore small in terms of code size. But it is also necessary that all code but the smallest and most highly protected code is also subjected to run-time periodic checks to discover whether (unauthorized) changes have been made.
The run-time periodic checks themselves, in turn, become attractive targets for the ever more ingenious malware perpetrators and the present invention addresses, inter alia, the issue of how the integrity and security of run-time periodic checks may themselves be hardened against attack.
Thus, the disclosed improved computer designs enable superior tradeoffs in regards to the problems outlined above, and more.